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REMARKS 

In the Final Office Action, claims 1-9 and 11-13 were rejected pursuant to 35 U.S.C. 
§112, first paragraph. The Examiner alleges that: the look-up table conversion from 2D display 
format to a 2D acquisition format is not shown since the acquisition format is a 3D data volume, 
and the 2D acquisition format with avoiding scan conversion of volume data not contributing to 
a final volume image is self contradictory. 

Claim 1 has been amended to remove the "two-dimensional" acquisition format. Claim 
1 and the corresponding dependent claims 2-9 and 1 1-13 are supported by the original 
disclosure. 

In the Advisory Action, the Examiner indicated that this rejection was overcome. 

In the Final Office Action, claims 14-20 and 22-27 were rejected pursuant to 34 U.S.C. 
§101 as being directed to non-statutory subject matter. Both claims 14 and 22 are directed to 
statutory subject matter. The transformation of data representing a patient into an image is 
directed to statutory subject matter (See In re Bilski ). 

In response, the Examiner alleges the claim is directed to change in format of data that 
has already been collected, so is not statutory. The Examiner notes that the steps of 
identification and interpolation are not tied to a machine. 

Independent claims 14 and 23 have been amended to require that the look-up table is in 
a memory and a processor performs the interpolating. These method claims are tied to a 
statutory class, so are directed to statutory subject matter. 

In the Advisory Action, the Examiner indicated that this rejection was overcome. 

As of the Advisory Action, the Examiner again rejected claims 1,3,5, 1 1-14, 16, 18, 
and 24-26 pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. (US 6,526,163) 
in view of Seller, et al. (EP 1,093,085). Claim 2 was rejected pursuant to 35 U.S.C. §103(a) as 
unpatentable over Halmann, et al. in view of Seller and further in view of Zar (A Scan 
Conversion Engine...). Claims 4 and 17 were rejected pursuant to 35 U.S.C. §103(a) as 
unpatentable over Halmann, et al. in view of Seller, et al and Hossack, et al. (US 6,352,51 1). 
Claims 6 and 19 were rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et 
al. in view of Seller, et al. and Okerlund, et al. (US 6,690,371). Claims 7 and 20 were rejected 
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pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of Seller, et al. and 
Drebin, et al. (US 4,835,712). Claims 9 and 22 were rejected pursuant to 35 U.S.C. §103(a) as 
unpatentable over Halmann, et al. in view of Seller, et al. and Swerdloff (US 5,483,567). Claim 
15 was rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of 
Seller, et al. and Fattah (US 7,274,325). Claim 27 was rejected pursuant to 35 U.S.C. § 1 03(a) 
as unpatentable over Halmann, et al. in view of Seller, et al. and Edic, et al. (US 2004/0136490). 

As of the Advisory Action, claims 10 and 23 were allowed. Claims 8 and 21 were 
objected to as being allowable if amended into independent form. 

Applicants respectfully request reconsideration of the rejections of claims 1-7, 1 1-20, 
22, and 24-27, including independent claims 1 and 14. Consideration of new claims 28 and 29 
is requested. 

Independent claim 1 recites a look-up table having values corresponding to a spatial 
conversion from Cartesian coordinates of the Cartesian format to polar coordinates of the 
polar format; and a processor configured to identify acquired ultrasound data corresponding 
to the polar coordinates as a function of the values, the polar coordinates identified as a 
function of the values using the look-up table for the spatial conversion from the Cartesian 
coordinates of a virtual volume free of voxel data, the processor operable to interpolate, in 
the polar format, from the identified acquired ultrasound data, the interpolation being a 
function of three-dimensional rendering rays cast through the virtual volume, wherein the 
processor is configured to avoid scan-conversion from the polar coordinates of volume data 
that does not contribute to a final volume rendered image by scan converting only visible 
voxels based on the rendering rays and corresponding Cartesian coordinates, the identifying 
corresponding to identifying Cartesian coordinates associated with visible voxels of the final 
volume rendered image. 

Claim 1 is allowable over Halmann, et al. and Seller, et al. for the previously argued 
reasons, not repeated here. Claim 1 is allowable for other reasons provided below. 

Halmann, et al. and Seller, et al. do not interpolate, in the polar format, from the 
identified acquired ultrasound data, the interpolation being a function of three-dimensional 
rendering rays cast through a volume. Halmann, et al. interpolate to form 2D images (col. 9, 
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lines 4-13) and volume render from the 2D images (col. 5, lines 34-40). The interpolation in 

the polar format is done without consideration of the rays cast through a volume. Seller, et 
al. operate on a volume data set of voxels (paragraph 2), so do not interpolate in the polar 
format from acquired ultrasound data. Halmann, et al. generate a volume data set by 
interpolation, and then render. Seller, et al. teach how to then render from the volume data 
set. Neither reference suggests interpolating in the polar format as a function of rendering 
rays. 

Halmann, et al. and Seller, et al. do not disclose identifying, for interpolation, 
Cartesian coordinates associated with visible voxels of the final volume rendered image. 
Seller, et al. identify voxels that are or are not visible regardless of the display coordinates. 
Halmann, et al. scan convert all data to 2D images and then use the volume data for 
rendering. Neither reference suggests identifying, for interpolation, Cartesian coordinates 
associated with visible voxels of the final volume rendered image. 

Halmann, et al. and Seller, et al. do not avoid scan-conversion from the polar 
coordinates of volume data that does not contribute to a final volume rendered image by scan 
converting only visible voxels based on the rendering rays and corresponding Cartesian 
coordinates. Halmann, et al. scan convert all data from the polar coordinates to the display 
Cartesian coordinates, and then volume render (col. 5, lines 34-40). Seller, et al. only load 
the pipeline with visible blocks of voxels (paragraph 30). Seller, et al. avoid loading data 
already in a Cartesian coordinate format. Neither reference suggests avoiding scan- 
conversion from the polar coordinates. 

Halmann, et al. and Seller, et al. do not use, with rendering rays, a virtual volume free of 
voxel data. Halmann, et al. provide for rendering by ray casting (col. 5, lines 34-40). The rays 
are cast through a volume data set constructed of a series of 2D images (col. 5, lines 34-40). 
The volume for ray casting is an actual volume of voxel data (e.g., 10 for point xl, yl, zl and 
23 for point x2, y2, z2), not a virtual volume free of voxel data. Seiler, et al. also cast rays 
through an actual volume data set (paragraphs 8, 9, and 32). Neither reference suggests use of a 
virtual volume free of voxel data with rendering rays. 

Independent claim 14 is allowable for similar reasons as claim 1. 
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Dependent claims 2-7, 9, 1 1-13, 15-20, 22, and 24-27 depend from claims 1 and 14, and 
are allowable for the same reasons as the corresponding base claim. Further limitations 
patentably distinguish from the cited references. 

Claim 2 recites that the values comprise Polar coordinates, the look-up table entries 
indexed by integer Cartesian coordinates and wherein the processor is operable to bilinearly 
interpolate from the look-up table values using fractional offsets of Cartesian coordinates. 
As noted by the inventor, Halmann, et al. state that a "scan converter module 207 converts 
incoming data from the Polar coordinate system to the Cartesian coordinate system" (column 
6, hnes 10-12)(emphasis added). Base claim 1 provides that samples passing through a 
"virtual" Cartesian volume are scan-converted by converting Cartesian coordinates to Polar 
coordinates, thereby the interpolation takes place in the Polar coordinate system - the 
opposite of what Halmann, et al. and Zar disclose. Claim 2 depends on Claim 1, where we 
have shown that Seiler does not teach the concept of a virtual Cartesian volume - instead he 
assumes that Cartesian voxel data already exists. 

Claims 3 and 16 recite determining the display coordinates of interest and identifying 
the acquired ultrasound data by input of the display coordinates into the look-up table. The 
Examiner cites to col. 8, lines 4-9 of Halmann, et al. Halmann, et al. may locate an area of 
interest, but the area is not used to identify acquired data by input into the look-up table. 
Identifying all ultrasound data is not using the area to identify data. 

The Examiner alleges that all the data is the area of interest. However, Halmann, et 
al. do not provide a process for less than all data being the area of interest. Accordingly, 
Halmann, et al. do not provide for identifying acquired data by input of determined display 
coordinates. 

Claims 5 and 18 recite the display coordinates of interest input to the look-up table 
being coordinates for a plurality of rays through the volume. Halmann, et al. disclose a 
raycasting/volume rendering module 201, but this module 201 is not shown to work with the 
tables of the separate scan conversion module 207. The Examiner alleges there is no way to 
render an image if the original coordinates are polar, but that is not true. The rendering can 
account for any coordinate system. The rendering, rather than scan conversion, may provide 
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data for each pixel based on ray casting, regardless of the format of the input data. Halmann, 
et al. do not put ray coordinates into a scan conversion look-up table. 

The Examiner notes that Halmann, et al. disclose lookup tables for scan conversion, 
so one skilled in the art would use tables with raycasting. However, Halmann, et al. treat 
rendering and scan conversion separately. Rendering, unlike scan conversion, is not 
disclosed as using tables. Instead, raycasting is used with interpolation along the rays. The 
interpolation to the rays and then blending provides the pixel values. 

Halmann, et al. do not treat the entire process as rendering. Instead, scan conversion 
is provided and then the rendering is performed. 

Claim 26 recites generating a two-dimensional look-up table with acquisition format 
coordinates for each coordinate of a Cartesian volume. Halmann, et al. treat volume 
rendering separately from scan conversion. There is no disclosure of a LUT for coordinates 
of a Cartesian volume. The Examiner alleges there is no way to render an image if the 
original coordinates are polar, but that is not true. The rendering can account for any 
coordinate system. Also, the process of Halmann, et al. may be used - convert from Polar to 
Cartesian. The image is rendered from a volume of Cartesian data, so a reverse table would 
not be used. 

Halmann, et al. treat rendering and scan conversion separately. Rendering, unlike 
scan conversion, is not disclosed as using tables. Instead, raycasting is used with 
interpolation along the rays. The interpolation to the rays and then blending provides the 
pixel values. 

Claim 4 recites the processor operable to determine a plane through a volume as the 
display coordinates where the display coordinates are input to the look-up table. Hossack, et 
al. show arbitrary plane display for a volume, but do not use the coordinates of the plane as 
an input to the look-up table. Halmann, et al. treat volume rendering and scan conversion 
separately, so do not use coordinates of a plane in a volume as input to the scan conversion 
table. The form of conversion used would be the form taught by Halmann, et al, not a 
reverse conversion that also intermixes the separate rendering process. Claim 17 is allowable 
for similar reasons. 
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The Examiner points out that some sort of conversion must be done to obtain display 
data and Halmann, et al. use the LUT for conversion. However, rendering a plane from a 
volume is not handled as scan conversion by Halmann, et al. In rendering, the display values 
are interpolated from the already scan converted volume. Hossack, et al. show scan 
conversion of 2D planes, such as performed by Halmann, et al. Halmann, et al. then perform 
rendering from the collected planes. A LUT is not disclosed as being used for rendering. 
The data is already in a Cartesian format. 

As noted by the inventor, by association with Claim 1, claims 4 and 17 imply that the 
cross-section is also computed by selective scan-conversion of only the samples required to 
form the image plane, as illustrated in Figure 5b of the application. Hossack, et al. describe a 
scan converter 34, stating "the scan converter comprises a device for reformatting polar 
coordinate ultrasound data into Cartesian coordinate ultrasound data" (column 5, lines 62- 
65), which is described as a separate module from the subsequent display step 36. Hossack, 
et al. do not teach a combined display and scan-conversion process where scan-conversion 
selectively skips samples which do not contribute to the final image. Hossack, et al. also do 
not teach the use of a "virtual" Cartesian volume which does not contain any voxel data - in 
fact, claims in Hossack, et al. focus solely on a method for persistence of ultrasound data, the 
opposite of our approach where no Cartesian volume data is ever persisted, and new samples 
are always scan-converted on the fly based on a particular observer location. 

Claims 6 and 19 are allowable for the same reasons as claim 5. Claims 6 and 19 are 
also allowable because Okerlund, et al., like Halmann, et al. and Seller, et al., do not treat 
rendering and scan conversion together. A collection of images or display formatted data is 
used to form the volume (col. 3, hues 47-60). 

As noted by the inventor, by association with the base claims, claim 6 and 19 
selectively avoid scan-conversion of volume data that does not contribute to a final volume 
rendered image. In 6,690,371, Okerlund describes a typical setup of a medical imaging 
workstation with a rendering component 86 which can visualize acquired medical data. 
Commercial systems as such have been available decades before Okerlund 's filing date of 
May 3, 2000 and his description of the rendering component does not teach anything new 
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other than one very particular idea, which was incorporated in the claims, where the 
visualization comprises the rapid production of a "reduced-fidelity" image by using a 
"decimated image volume" which gets refined to a full-fidelity image in subsequent steps. 
Okerlund does not teach the idea of sampling a "virtual" Cartesian volume and selectively 
scan-convert only the samples that contribute to the final image through inverse look-up. In 
addition, the recited system does not rely on decimated "reduce-fidelity" data - in fact, the 
claimed approach produces results that are superior even to the "full-fidelity" images 
described by Okerlund, and superior to images which would be produced by Halmann, et al. 
and Seller. By scan-converting data prior to rendering, Halmann, et al. rely on existing voxel 
values in a Cartesian dataset, and therefore during rendering his method interpolates 
Cartesian voxel values. Such values have already undergone a previous interpolation step 
from Polar to Cartesian in the scan converter module, therefore Halmann' s approach 
interpolates two times and as a result the image quality is blurrier. Seller perform the same 
multiple interpolation. In the recited approach of claims 6 and 19, the "virtual" Cartesian 
volume does not contain any data, and each sample is interpolated on the fly only once from 
Polar data - we therefore have one less interpolation step, and the image quality is improved 
compared to systems relying on Halmann, et al., Okerlund, and Seller, et al. 

Claim 12 recites a flag, and an integer sum. As noted in the specification, an integer 
sum allows indication of spatial relationship relative to other table entries. Halmann, et al. 
do not suggest any format for the look-up table, and certainly do not disclose an integer sum, 
a flag or fixed-point values. These values are chosen to allow table based identification of 
data rather than scan conversion of the data. Selective scan conversion of only the samples 
that contribute to the rendering result without having to scan convert occluded data is 
provided by the recited table variables. A person of ordinary skill in the art would not have 
provided the listed classes as a mere design choice. The flag and integer sum would not have 
been considered as there is no reason for them in Halmann, et al. Just being well known is 
insufficient. 

The Examiner notes that there is no reason to use a flag and integer sum in Halmann, 
et al. and alleges the same for the invention, so that they are a design choice. The Examiner 



- 16- 



ATTORNEY DOCKET NO. 

2002P19673US01 



then alleges that the claimed invention does not recite indication of a spatial relationship and 
that other variables may work. However, the claimed invention is about scan conversion, 
which is a spatial relationship. The flag and integer sum efficiently track visibility for the 
claimed reverse lookup. Given the teachings of Halmann, et al., a person of ordinary skill in 
the art would not have used the flag and integer sum as a design choice. 



Applicants respectfully submit that all of the pending claims are in condition for 
allowance and seeks early allowance thereof. 

PLEASE MAIL CORRESPONDENCE TO: Respectfully submitted. 



CONCLUSION : 



/Rosa S. Kim/ 
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